--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
>  
> You can either use a spare (disabled) axis channel or an axis channel that doesn't currently use an input (open loop Step/Dir Axis).  The encoder input will only be used by the axis for modes that require it.  For (open loop) Step/Dir mode the Encoder Position will be maintained but not used.  Also the Axis does not need to be enabled to maintain the Encoder Position.  The Encoder Position can be accessed as ch0->Position.
>  
> Regards
> TK 
>
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Sunday, June 17, 2012 5:05 PM
> Subject: [DynoMotion] Re: MPG Confusion....
>
>
>  
> Tom,
>
> OK, reading this in software seems to just not work at high speed. I wrote a dead-simple routine that works perfectly at low speed, but I can easily make it skip steps by spinning the MPG fast. So, it appears I have no choice but to use a hardware encoder input. But how do I configure it to do that without that encoder also becoming feedback to an axis? My drives are using step/dir outputs 0, and 4-7, and the 1-3 encoder pins are all currently in use, so I'll have to figure out how to move two of them. Can I just define an input channel for one of the existing axes, and set it's gain to zero? How/Where do I read encoder position?
>
> Regards,
> Ray L.
>
> --- In mailto:DynoMotion%40yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> >
> > The MPGSmooth.c example uses a tricky technique to allow high quadrature count rates in software.  Because the User program only runs every 180us the count rate would be limited to about ~5KHz so that it would be guaranteed to see every quadrature transition.  Using the trick the routine can count up to ~100KHz reliably. The trick assumes that the velocity can change very little over several 180us time periods.  It estimates how many quadrature transitions were expected to be missed and syncs to the matching quadrature state (-1, 0, or +1) from the estimate.  BTW an important requirement of the "trick" is that it averages the last two deltas (change1 and change2) so that it can obtain an estimate within +/- 0.5 counts.
> >
> > In your case with quadrature transitions coming out in bursts and stops rather than uniformly like a normal encoder I can see how the routine can get all confused.  A big disadvantage with the "trick" is that erratic data can cause it to get confused and think unchanging quadrature is aliased sampling of a high speed motion.
> >
> > If you simplify the routine to defeat the "trick" then it will never get confused but the count rate will be limited to ~5KHz.  A simple change is to set Change1 and Change2 to zero at the end of the loop so as the previous estimate of speed will always be zero.
> >
> > Otherwise connect to a real hardware encoder input that will count correctly regardless of how erratic the counts are (up to 1MHz).
> >
> > Regards
> > TK
> >
> >
> >
> > ________________________________
> > From: himykabibble <jagboy@>
> > To: mailto:DynoMotion%40yahoogroups.com
> > Sent: Sunday, June 17, 2012 9:02 AM
> > Subject: [DynoMotion] Re: MPG Confusion....
> >
> >
> >
> >  
> > I now think I see what is happening, but don't understand how.... When I spin the MPG fast, the quadrature code seems to be getting itself into a bizarro state where it always indicates a change, even when the MPG is not turning. And the change is often large - I've seen "Change1" stuck with a value as high as 24, which basically says "Jog real fast in that direction, and don't ever stop". I can't fathom what is happening there, as I don't understand what that code is doing.... If I don't turn the MPG too fast, all works perfectly.
> >
> > Regards,
> > Ray L.
> >
> > --- In mailto:DynoMotion%40yahoogroups.com, "himykabibble" <jagboy@> wrote:
> > >
> > > Tom,
> > >
> > > I don't know what the encoder is, but the pendant is a VistaCNC P2. When I first discovered what it was doing, I contacted Lee (Mr. VistaCNC), and he confirmed that the behavior was correct. It doesn't make a lot of sense to me but that is exactly what it is doing.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In mailto:DynoMotion%40yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > >
> > > > Hi Ray,
> > > >
> > > > I don't see how the encoder can put out all 4 quadrature states at once.  I've never heard of anything like that.  What kind is it?
> > > >
> > > > Regards
> > > > TK
> > > >
> > > >
> > > >
> > > >
> > > > ________________________________
> > > > From: himykabibble <jagboy@>
> > > > To: mailto:DynoMotion%40yahoogroups.com
> > > > Sent: Saturday, June 16, 2012 5:48 PM
> > > > Subject: [DynoMotion] MPG Confusion....
> > > >
> > > >
> > > >  
> > > > I've got most of the functionality of my new pendant working. The firmware for the pendant is done, and working perfectly, and I'm well along the way on the KFlop software. Using RS232 to communicate all status other than the MPG and E-Stop (though it does send E-Stop message over RS232 as well as providing a switch closure) makes the KFlop software really trivial.
> > > >
> > > > The only issues I'm having center around the MPG. This pendant has a "real" MPG - 100 "clicks" per turn, and each "click" outputs all four quadrature states, so it's 400 "counts" per turn. I was expecting it to advance only one quadrature state per "click", like my old one. Is this normal for good MPGs?
> > > >
> > > > Anyway, it's working OK, unless I turn it very quickly. Right now, I'm acting on it each timeslice, which means it will take at least four timeslices to fully process one "click" on the MPG, assuming no lost states. I'm using the MPGSmooth.c example code, and it works fine, unless I turn the MPG quickly, then it starts throwing direction reversals in.
> > > >
> > > > So, is the behavior of the MPG "typical"? If so, what is the logic there? Why not simple output one phase change per click? Any ideas why I'm getting such poor high-speed performance? This was not a problem with my old, very poor quality, albeit low res @ 36 phase steps/turn, MPG.
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > >
> >
>

--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> Tom,
>
> I'm trying to use the ch0 encoder input. The ch0->OutputChan is 12. Is there anything more I need to do than setting ch0->InputChan0 = 1? I've got it connected, but I'm not seeing anything on the axis page.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> >  
> > You can either use a spare (disabled) axis channel or an axis channel that doesn't currently use an input (open loop Step/Dir Axis).  The encoder input will only be used by the axis for modes that require it.  For (open loop) Step/Dir mode the Encoder Position will be maintained but not used.  Also the Axis does not need to be enabled to maintain the Encoder Position.  The Encoder Position can be accessed as ch0->Position.
> >  
> > Regards
> > TK 
> >
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Sunday, June 17, 2012 5:05 PM
> > Subject: [DynoMotion] Re: MPG Confusion....
> >
> >
> >  
> > Tom,
> >
> > OK, reading this in software seems to just not work at high speed. I wrote a dead-simple routine that works perfectly at low speed, but I can easily make it skip steps by spinning the MPG fast. So, it appears I have no choice but to use a hardware encoder input. But how do I configure it to do that without that encoder also becoming feedback to an axis? My drives are using step/dir outputs 0, and 4-7, and the 1-3 encoder pins are all currently in use, so I'll have to figure out how to move two of them. Can I just define an input channel for one of the existing axes, and set it's gain to zero? How/Where do I read encoder position?
> >
> > Regards,
> > Ray L.
> >
> > --- In mailto:DynoMotion%40yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Ray,
> > >
> > > The MPGSmooth.c example uses a tricky technique to allow high quadrature count rates in software.  Because the User program only runs every 180us the count rate would be limited to about ~5KHz so that it would be guaranteed to see every quadrature transition.  Using the trick the routine can count up to ~100KHz reliably. The trick assumes that the velocity can change very little over several 180us time periods.  It estimates how many quadrature transitions were expected to be missed and syncs to the matching quadrature state (-1, 0, or +1) from the estimate.  BTW an important requirement of the "trick" is that it averages the last two deltas (change1 and change2) so that it can obtain an estimate within +/- 0.5 counts.
> > >
> > > In your case with quadrature transitions coming out in bursts and stops rather than uniformly like a normal encoder I can see how the routine can get all confused.  A big disadvantage with the "trick" is that erratic data can cause it to get confused and think unchanging quadrature is aliased sampling of a high speed motion.
> > >
> > > If you simplify the routine to defeat the "trick" then it will never get confused but the count rate will be limited to ~5KHz.  A simple change is to set Change1 and Change2 to zero at the end of the loop so as the previous estimate of speed will always be zero.
> > >
> > > Otherwise connect to a real hardware encoder input that will count correctly regardless of how erratic the counts are (up to 1MHz).
> > >
> > > Regards
> > > TK
> > >
> > >
> > >
> > > ________________________________
> > > From: himykabibble <jagboy@>
> > > To: mailto:DynoMotion%40yahoogroups.com
> > > Sent: Sunday, June 17, 2012 9:02 AM
> > > Subject: [DynoMotion] Re: MPG Confusion....
> > >
> > >
> > >
> > >  
> > > I now think I see what is happening, but don't understand how.... When I spin the MPG fast, the quadrature code seems to be getting itself into a bizarro state where it always indicates a change, even when the MPG is not turning. And the change is often large - I've seen "Change1" stuck with a value as high as 24, which basically says "Jog real fast in that direction, and don't ever stop". I can't fathom what is happening there, as I don't understand what that code is doing.... If I don't turn the MPG too fast, all works perfectly.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In mailto:DynoMotion%40yahoogroups.com, "himykabibble" <jagboy@> wrote:
> > > >
> > > > Tom,
> > > >
> > > > I don't know what the encoder is, but the pendant is a VistaCNC P2. When I first discovered what it was doing, I contacted Lee (Mr. VistaCNC), and he confirmed that the behavior was correct. It doesn't make a lot of sense to me but that is exactly what it is doing.
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In mailto:DynoMotion%40yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > >
> > > > > Hi Ray,
> > > > >
> > > > > I don't see how the encoder can put out all 4 quadrature states at once.  I've never heard of anything like that.  What kind is it?
> > > > >
> > > > > Regards
> > > > > TK
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ________________________________
> > > > > From: himykabibble <jagboy@>
> > > > > To: mailto:DynoMotion%40yahoogroups.com
> > > > > Sent: Saturday, June 16, 2012 5:48 PM
> > > > > Subject: [DynoMotion] MPG Confusion....
> > > > >
> > > > >
> > > > >  
> > > > > I've got most of the functionality of my new pendant working. The firmware for the pendant is done, and working perfectly, and I'm well along the way on the KFlop software. Using RS232 to communicate all status other than the MPG and E-Stop (though it does send E-Stop message over RS232 as well as providing a switch closure) makes the KFlop software really trivial.
> > > > >
> > > > > The only issues I'm having center around the MPG. This pendant has a "real" MPG - 100 "clicks" per turn, and each "click" outputs all four quadrature states, so it's 400 "counts" per turn. I was expecting it to advance only one quadrature state per "click", like my old one. Is this normal for good MPGs?
> > > > >
> > > > > Anyway, it's working OK, unless I turn it very quickly. Right now, I'm acting on it each timeslice, which means it will take at least four timeslices to fully process one "click" on the MPG, assuming no lost states. I'm using the MPGSmooth.c example code, and it works fine, unless I turn the MPG quickly, then it starts throwing direction reversals in.
> > > > >
> > > > > So, is the behavior of the MPG "typical"? If so, what is the logic there? Why not simple output one phase change per click? Any ideas why I'm getting such poor high-speed performance? This was not a problem with my old, very poor quality, albeit low res @ 36 phase steps/turn, MPG.
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > >
> > >
> >
>

--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> Correction - I'm trying to use the ch1 encoder input on channel 0.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> >
> > Tom,
> >
> > I'm trying to use the ch0 encoder input. The ch0->OutputChan is 12. Is there anything more I need to do than setting ch0->InputChan0 = 1? I've got it connected, but I'm not seeing anything on the axis page.
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Ray,
> > >  
> > > You can either use a spare (disabled) axis channel or an axis channel that doesn't currently use an input (open loop Step/Dir Axis).  The encoder input will only be used by the axis for modes that require it.  For (open loop) Step/Dir mode the Encoder Position will be maintained but not used.  Also the Axis does not need to be enabled to maintain the Encoder Position.  The Encoder Position can be accessed as ch0->Position.
> > >  
> > > Regards
> > > TK 
> > >
> > > From: himykabibble <jagboy@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Sunday, June 17, 2012 5:05 PM
> > > Subject: [DynoMotion] Re: MPG Confusion....
> > >
> > >
> > >  
> > > Tom,
> > >
> > > OK, reading this in software seems to just not work at high speed. I wrote a dead-simple routine that works perfectly at low speed, but I can easily make it skip steps by spinning the MPG fast. So, it appears I have no choice but to use a hardware encoder input. But how do I configure it to do that without that encoder also becoming feedback to an axis? My drives are using step/dir outputs 0, and 4-7, and the 1-3 encoder pins are all currently in use, so I'll have to figure out how to move two of them. Can I just define an input channel for one of the existing axes, and set it's gain to zero? How/Where do I read encoder position?
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In mailto:DynoMotion%40yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > >
> > > > Hi Ray,
> > > >
> > > > The MPGSmooth.c example uses a tricky technique to allow high quadrature count rates in software.  Because the User program only runs every 180us the count rate would be limited to about ~5KHz so that it would be guaranteed to see every quadrature transition.  Using the trick the routine can count up to ~100KHz reliably. The trick assumes that the velocity can change very little over several 180us time periods.  It estimates how many quadrature transitions were expected to be missed and syncs to the matching quadrature state (-1, 0, or +1) from the estimate.  BTW an important requirement of the "trick" is that it averages the last two deltas (change1 and change2) so that it can obtain an estimate within +/- 0.5 counts.
> > > >
> > > > In your case with quadrature transitions coming out in bursts and stops rather than uniformly like a normal encoder I can see how the routine can get all confused.  A big disadvantage with the "trick" is that erratic data can cause it to get confused and think unchanging quadrature is aliased sampling of a high speed motion.
> > > >
> > > > If you simplify the routine to defeat the "trick" then it will never get confused but the count rate will be limited to ~5KHz.  A simple change is to set Change1 and Change2 to zero at the end of the loop so as the previous estimate of speed will always be zero.
> > > >
> > > > Otherwise connect to a real hardware encoder input that will count correctly regardless of how erratic the counts are (up to 1MHz).
> > > >
> > > > Regards
> > > > TK
> > > >
> > > >
> > > >
> > > > ________________________________
> > > > From: himykabibble <jagboy@>
> > > > To: mailto:DynoMotion%40yahoogroups.com
> > > > Sent: Sunday, June 17, 2012 9:02 AM
> > > > Subject: [DynoMotion] Re: MPG Confusion....
> > > >
> > > >
> > > >
> > > >  
> > > > I now think I see what is happening, but don't understand how.... When I spin the MPG fast, the quadrature code seems to be getting itself into a bizarro state where it always indicates a change, even when the MPG is not turning. And the change is often large - I've seen "Change1" stuck with a value as high as 24, which basically says "Jog real fast in that direction, and don't ever stop". I can't fathom what is happening there, as I don't understand what that code is doing.... If I don't turn the MPG too fast, all works perfectly.
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In mailto:DynoMotion%40yahoogroups.com, "himykabibble" <jagboy@> wrote:
> > > > >
> > > > > Tom,
> > > > >
> > > > > I don't know what the encoder is, but the pendant is a VistaCNC P2. When I first discovered what it was doing, I contacted Lee (Mr. VistaCNC), and he confirmed that the behavior was correct. It doesn't make a lot of sense to me but that is exactly what it is doing.
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > > > --- In mailto:DynoMotion%40yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > >
> > > > > > Hi Ray,
> > > > > >
> > > > > > I don't see how the encoder can put out all 4 quadrature states at once.  I've never heard of anything like that.  What kind is it?
> > > > > >
> > > > > > Regards
> > > > > > TK
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > ________________________________
> > > > > > From: himykabibble <jagboy@>
> > > > > > To: mailto:DynoMotion%40yahoogroups.com
> > > > > > Sent: Saturday, June 16, 2012 5:48 PM
> > > > > > Subject: [DynoMotion] MPG Confusion....
> > > > > >
> > > > > >
> > > > > >  
> > > > > > I've got most of the functionality of my new pendant working. The firmware for the pendant is done, and working perfectly, and I'm well along the way on the KFlop software. Using RS232 to communicate all status other than the MPG and E-Stop (though it does send E-Stop message over RS232 as well as providing a switch closure) makes the KFlop software really trivial.
> > > > > >
> > > > > > The only issues I'm having center around the MPG. This pendant has a "real" MPG - 100 "clicks" per turn, and each "click" outputs all four quadrature states, so it's 400 "counts" per turn. I was expecting it to advance only one quadrature state per "click", like my old one. Is this normal for good MPGs?
> > > > > >
> > > > > > Anyway, it's working OK, unless I turn it very quickly. Right now, I'm acting on it each timeslice, which means it will take at least four timeslices to fully process one "click" on the MPG, assuming no lost states. I'm using the MPGSmooth.c example code, and it works fine, unless I turn the MPG quickly, then it starts throwing direction reversals in.
> > > > > >
> > > > > > So, is the behavior of the MPG "typical"? If so, what is the logic there? Why not simple output one phase change per click? Any ideas why I'm getting such poor high-speed performance? This was not a problem with my old, very poor quality, albeit low res @ 36 phase steps/turn, MPG.
> > > > > >
> > > > > > Regards,
> > > > > > Ray L.
> > > > > >
> > > > > > Regards,
> > > > > > Ray L.
> > > > > >
> > > > >
> > > >
> > >
> >
>

--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> Just to be really clear.... My ch0 axis structure init is below. I have the encoder on I/Os 2 & 3, on JP7-9 & 10. I do see the pins toggle when I turn the encoder, but the position on the axis page never changes. The axis does show enabled on the axis page.
>
> ch0->InputMode=NO_INPUT_MODE;
> ch0->OutputMode=STEP_DIR_MODE;
> ch0->Vel=X_MAX_VEL_COUNTS;
> ch0->Accel=X_ACCEL_COUNTS_PER_SEC2;
> ch0->Jerk=X_JERK;
> ch0->P=0;
> ch0->I=0.01;
> ch0->D=0;
> ch0->FFAccel=0;
> ch0->FFVel=0;
> ch0->MaxI=200;
> ch0->MaxErr=1e+006;
> ch0->MaxOutput=200;
> ch0->DeadBandGain=1;
> ch0->DeadBandRange=0;
> ch0->InputChan0=1;
> ch0->InputChan1=0;
> ch0->OutputChan0=12;
> ch0->OutputChan1=0;
> ch0->MasterAxis=-1;
> ch0->LimitSwitchOptions=0x0;
> ch0->InputGain0=1;
> ch0->InputGain1=1;
> ch0->InputOffset0=0;
> ch0->InputOffset1=0;
> ch0->OutputGain=1;
> ch0->OutputOffset=0;
> ch0->SlaveGain=1;
> ch0->BacklashMode=BACKLASH_OFF;
> ch0->BacklashAmount=0;
> ch0->BacklashRate=0;
> ch0->invDistPerCycle=1;
> ch0->Lead=0;
> ch0->MaxFollowingError=1000000000;
> ch0->StepperAmplitude=20;
>
> Regards,
> Ray L.
>
>
>
> --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> >
> > Correction - I'm trying to use the ch1 encoder input on channel 0.
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> > >
> > > Tom,
> > >
> > > I'm trying to use the ch0 encoder input. The ch0->OutputChan is 12. Is there anything more I need to do than setting ch0->InputChan0 = 1? I've got it connected, but I'm not seeing anything on the axis page.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > >
> > > > Hi Ray,
> > > >  
> > > > You can either use a spare (disabled) axis channel or an axis channel that doesn't currently use an input (open loop Step/Dir Axis).  The encoder input will only be used by the axis for modes that require it.  For (open loop) Step/Dir mode the Encoder Position will be maintained but not used.  Also the Axis does not need to be enabled to maintain the Encoder Position.  The Encoder Position can be accessed as ch0->Position.
> > > >  
> > > > Regards
> > > > TK 
> > > >
> > > > From: himykabibble <jagboy@>
> > > > To: DynoMotion@yahoogroups.com
> > > > Sent: Sunday, June 17, 2012 5:05 PM
> > > > Subject: [DynoMotion] Re: MPG Confusion....
> > > >
> > > >
> > > >  
> > > > Tom,
> > > >
> > > > OK, reading this in software seems to just not work at high speed. I wrote a dead-simple routine that works perfectly at low speed, but I can easily make it skip steps by spinning the MPG fast. So, it appears I have no choice but to use a hardware encoder input. But how do I configure it to do that without that encoder also becoming feedback to an axis? My drives are using step/dir outputs 0, and 4-7, and the 1-3 encoder pins are all currently in use, so I'll have to figure out how to move two of them. Can I just define an input channel for one of the existing axes, and set it's gain to zero? How/Where do I read encoder position?
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In mailto:DynoMotion%40yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > >
> > > > > Hi Ray,
> > > > >
> > > > > The MPGSmooth.c example uses a tricky technique to allow high quadrature count rates in software.  Because the User program only runs every 180us the count rate would be limited to about ~5KHz so that it would be guaranteed to see every quadrature transition.  Using the trick the routine can count up to ~100KHz reliably. The trick assumes that the velocity can change very little over several 180us time periods.  It estimates how many quadrature transitions were expected to be missed and syncs to the matching quadrature state (-1, 0, or +1) from the estimate.  BTW an important requirement of the "trick" is that it averages the last two deltas (change1 and change2) so that it can obtain an estimate within +/- 0.5 counts.
> > > > >
> > > > > In your case with quadrature transitions coming out in bursts and stops rather than uniformly like a normal encoder I can see how the routine can get all confused.  A big disadvantage with the "trick" is that erratic data can cause it to get confused and think unchanging quadrature is aliased sampling of a high speed motion.
> > > > >
> > > > > If you simplify the routine to defeat the "trick" then it will never get confused but the count rate will be limited to ~5KHz.  A simple change is to set Change1 and Change2 to zero at the end of the loop so as the previous estimate of speed will always be zero.
> > > > >
> > > > > Otherwise connect to a real hardware encoder input that will count correctly regardless of how erratic the counts are (up to 1MHz).
> > > > >
> > > > > Regards
> > > > > TK
> > > > >
> > > > >
> > > > >
> > > > > ________________________________
> > > > > From: himykabibble <jagboy@>
> > > > > To: mailto:DynoMotion%40yahoogroups.com
> > > > > Sent: Sunday, June 17, 2012 9:02 AM
> > > > > Subject: [DynoMotion] Re: MPG Confusion....
> > > > >
> > > > >
> > > > >
> > > > >  
> > > > > I now think I see what is happening, but don't understand how.... When I spin the MPG fast, the quadrature code seems to be getting itself into a bizarro state where it always indicates a change, even when the MPG is not turning. And the change is often large - I've seen "Change1" stuck with a value as high as 24, which basically says "Jog real fast in that direction, and don't ever stop". I can't fathom what is happening there, as I don't understand what that code is doing.... If I don't turn the MPG too fast, all works perfectly.
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > > > --- In mailto:DynoMotion%40yahoogroups.com, "himykabibble" <jagboy@> wrote:
> > > > > >
> > > > > > Tom,
> > > > > >
> > > > > > I don't know what the encoder is, but the pendant is a VistaCNC P2. When I first discovered what it was doing, I contacted Lee (Mr. VistaCNC), and he confirmed that the behavior was correct. It doesn't make a lot of sense to me but that is exactly what it is doing.
> > > > > >
> > > > > > Regards,
> > > > > > Ray L.
> > > > > >
> > > > > > --- In mailto:DynoMotion%40yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > > >
> > > > > > > Hi Ray,
> > > > > > >
> > > > > > > I don't see how the encoder can put out all 4 quadrature states at once.  I've never heard of anything like that.  What kind is it?
> > > > > > >
> > > > > > > Regards
> > > > > > > TK
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ________________________________
> > > > > > > From: himykabibble <jagboy@>
> > > > > > > To: mailto:DynoMotion%40yahoogroups.com
> > > > > > > Sent: Saturday, June 16, 2012 5:48 PM
> > > > > > > Subject: [DynoMotion] MPG Confusion....
> > > > > > >
> > > > > > >
> > > > > > >  
> > > > > > > I've got most of the functionality of my new pendant working. The firmware for the pendant is done, and working perfectly, and I'm well along the way on the KFlop software. Using RS232 to communicate all status other than the MPG and E-Stop (though it does send E-Stop message over RS232 as well as providing a switch closure) makes the KFlop software really trivial.
> > > > > > >
> > > > > > > The only issues I'm having center around the MPG. This pendant has a "real" MPG - 100 "clicks" per turn, and each "click" outputs all four quadrature states, so it's 400 "counts" per turn. I was expecting it to advance only one quadrature state per "click", like my old one. Is this normal for good MPGs?
> > > > > > >
> > > > > > > Anyway, it's working OK, unless I turn it very quickly. Right now, I'm acting on it each timeslice, which means it will take at least four timeslices to fully process one "click" on the MPG, assuming no lost states. I'm using the MPGSmooth.c example code, and it works fine, unless I turn the MPG quickly, then it starts throwing direction reversals in.
> > > > > > >
> > > > > > > So, is the behavior of the MPG "typical"? If so, what is the logic there? Why not simple output one phase change per click? Any ideas why I'm getting such poor high-speed performance? This was not a problem with my old, very poor quality, albeit low res @ 36 phase steps/turn, MPG.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Ray L.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Ray L.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> OK, never mind..... I got it working.....
>
> --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> >
> > Just to be really clear.... My ch0 axis structure init is below. I have the encoder on I/Os 2 & 3, on JP7-9 & 10. I do see the pins toggle when I turn the encoder, but the position on the axis page never changes. The axis does show enabled on the axis page.
> >
> > ch0->InputMode=NO_INPUT_MODE;
> > ch0->OutputMode=STEP_DIR_MODE;
> > ch0->Vel=X_MAX_VEL_COUNTS;
> > ch0->Accel=X_ACCEL_COUNTS_PER_SEC2;
> > ch0->Jerk=X_JERK;
> > ch0->P=0;
> > ch0->I=0.01;
> > ch0->D=0;
> > ch0->FFAccel=0;
> > ch0->FFVel=0;
> > ch0->MaxI=200;
> > ch0->MaxErr=1e+006;
> > ch0->MaxOutput=200;
> > ch0->DeadBandGain=1;
> > ch0->DeadBandRange=0;
> > ch0->InputChan0=1;
> > ch0->InputChan1=0;
> > ch0->OutputChan0=12;
> > ch0->OutputChan1=0;
> > ch0->MasterAxis=-1;
> > ch0->LimitSwitchOptions=0x0;
> > ch0->InputGain0=1;
> > ch0->InputGain1=1;
> > ch0->InputOffset0=0;
> > ch0->InputOffset1=0;
> > ch0->OutputGain=1;
> > ch0->OutputOffset=0;
> > ch0->SlaveGain=1;
> > ch0->BacklashMode=BACKLASH_OFF;
> > ch0->BacklashAmount=0;
> > ch0->BacklashRate=0;
> > ch0->invDistPerCycle=1;
> > ch0->Lead=0;
> > ch0->MaxFollowingError=1000000000;
> > ch0->StepperAmplitude=20;
> >
> > Regards,
> > Ray L.
> >
> >
> >
> > --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> > >
> > > Correction - I'm trying to use the ch1 encoder input on channel 0.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> > > >
> > > > Tom,
> > > >
> > > > I'm trying to use the ch0 encoder input. The ch0->OutputChan is 12. Is there anything more I need to do than setting ch0->InputChan0 = 1? I've got it connected, but I'm not seeing anything on the axis page.
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > >
> > > > > Hi Ray,
> > > > >  
> > > > > You can either use a spare (disabled) axis channel or an axis channel that doesn't currently use an input (open loop Step/Dir Axis).  The encoder input will only be used by the axis for modes that require it.  For (open loop) Step/Dir mode the Encoder Position will be maintained but not used.  Also the Axis does not need to be enabled to maintain the Encoder Position.  The Encoder Position can be accessed as ch0->Position.
> > > > >  
> > > > > Regards
> > > > > TK 
> > > > >
> > > > > From: himykabibble <jagboy@>
> > > > > To: DynoMotion@yahoogroups.com
> > > > > Sent: Sunday, June 17, 2012 5:05 PM
> > > > > Subject: [DynoMotion] Re: MPG Confusion....
> > > > >
> > > > >
> > > > >  
> > > > > Tom,
> > > > >
> > > > > OK, reading this in software seems to just not work at high speed. I wrote a dead-simple routine that works perfectly at low speed, but I can easily make it skip steps by spinning the MPG fast. So, it appears I have no choice but to use a hardware encoder input. But how do I configure it to do that without that encoder also becoming feedback to an axis? My drives are using step/dir outputs 0, and 4-7, and the 1-3 encoder pins are all currently in use, so I'll have to figure out how to move two of them. Can I just define an input channel for one of the existing axes, and set it's gain to zero? How/Where do I read encoder position?
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > > > --- In mailto:DynoMotion%40yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > >
> > > > > > Hi Ray,
> > > > > >
> > > > > > The MPGSmooth.c example uses a tricky technique to allow high quadrature count rates in software.  Because the User program only runs every 180us the count rate would be limited to about ~5KHz so that it would be guaranteed to see every quadrature transition.  Using the trick the routine can count up to ~100KHz reliably. The trick assumes that the velocity can change very little over several 180us time periods.  It estimates how many quadrature transitions were expected to be missed and syncs to the matching quadrature state (-1, 0, or +1) from the estimate.  BTW an important requirement of the "trick" is that it averages the last two deltas (change1 and change2) so that it can obtain an estimate within +/- 0.5 counts.
> > > > > >
> > > > > > In your case with quadrature transitions coming out in bursts and stops rather than uniformly like a normal encoder I can see how the routine can get all confused.  A big disadvantage with the "trick" is that erratic data can cause it to get confused and think unchanging quadrature is aliased sampling of a high speed motion.
> > > > > >
> > > > > > If you simplify the routine to defeat the "trick" then it will never get confused but the count rate will be limited to ~5KHz.  A simple change is to set Change1 and Change2 to zero at the end of the loop so as the previous estimate of speed will always be zero.
> > > > > >
> > > > > > Otherwise connect to a real hardware encoder input that will count correctly regardless of how erratic the counts are (up to 1MHz).
> > > > > >
> > > > > > Regards
> > > > > > TK
> > > > > >
> > > > > >
> > > > > >
> > > > > > ________________________________
> > > > > > From: himykabibble <jagboy@>
> > > > > > To: mailto:DynoMotion%40yahoogroups.com
> > > > > > Sent: Sunday, June 17, 2012 9:02 AM
> > > > > > Subject: [DynoMotion] Re: MPG Confusion....
> > > > > >
> > > > > >
> > > > > >
> > > > > >  
> > > > > > I now think I see what is happening, but don't understand how.... When I spin the MPG fast, the quadrature code seems to be getting itself into a bizarro state where it always indicates a change, even when the MPG is not turning. And the change is often large - I've seen "Change1" stuck with a value as high as 24, which basically says "Jog real fast in that direction, and don't ever stop". I can't fathom what is happening there, as I don't understand what that code is doing.... If I don't turn the MPG too fast, all works perfectly.
> > > > > >
> > > > > > Regards,
> > > > > > Ray L.
> > > > > >
> > > > > > --- In mailto:DynoMotion%40yahoogroups.com, "himykabibble" <jagboy@> wrote:
> > > > > > >
> > > > > > > Tom,
> > > > > > >
> > > > > > > I don't know what the encoder is, but the pendant is a VistaCNC P2. When I first discovered what it was doing, I contacted Lee (Mr. VistaCNC), and he confirmed that the behavior was correct. It doesn't make a lot of sense to me but that is exactly what it is doing.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Ray L.
> > > > > > >
> > > > > > > --- In mailto:DynoMotion%40yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > > > >
> > > > > > > > Hi Ray,
> > > > > > > >
> > > > > > > > I don't see how the encoder can put out all 4 quadrature states at once.  I've never heard of anything like that.  What kind is it?
> > > > > > > >
> > > > > > > > Regards
> > > > > > > > TK
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ________________________________
> > > > > > > > From: himykabibble <jagboy@>
> > > > > > > > To: mailto:DynoMotion%40yahoogroups.com
> > > > > > > > Sent: Saturday, June 16, 2012 5:48 PM
> > > > > > > > Subject: [DynoMotion] MPG Confusion....
> > > > > > > >
> > > > > > > >
> > > > > > > >  
> > > > > > > > I've got most of the functionality of my new pendant working. The firmware for the pendant is done, and working perfectly, and I'm well along the way on the KFlop software. Using RS232 to communicate all status other than the MPG and E-Stop (though it does send E-Stop message over RS232 as well as providing a switch closure) makes the KFlop software really trivial.
> > > > > > > >
> > > > > > > > The only issues I'm having center around the MPG. This pendant has a "real" MPG - 100 "clicks" per turn, and each "click" outputs all four quadrature states, so it's 400 "counts" per turn. I was expecting it to advance only one quadrature state per "click", like my old one. Is this normal for good MPGs?
> > > > > > > >
> > > > > > > > Anyway, it's working OK, unless I turn it very quickly. Right now, I'm acting on it each timeslice, which means it will take at least four timeslices to fully process one "click" on the MPG, assuming no lost states. I'm using the MPGSmooth.c example code, and it works fine, unless I turn the MPG quickly, then it starts throwing direction reversals in.
> > > > > > > >
> > > > > > > > So, is the behavior of the MPG "typical"? If so, what is the logic there? Why not simple output one phase change per click? Any ideas why I'm getting such poor high-speed performance? This was not a problem with my old, very poor quality, albeit low res @ 36 phase steps/turn, MPG.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Ray L.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Ray L.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>